Conventional enterprise business applications exist that, for a variety of reasons, include identical data in multiple locations. Examples of data that may appear in multiple locations include a person's name, address, and social security number. For example, some or all of this data may be included (or associated) with information about the person's compensation information, work assignment, or citizenship status.
When particular pieces or types of data are required to be consistent throughout a database system, it is generally not problematic to synchronize such data accordingly. For example, a person's name will generally be consistent throughout a database system. If the person's name changes (for example, due to marriage), then a single change is usually sufficient to accurately reflect this change throughout the database system.
Data modification may be similarly straight-forward when particular pieces or types of data are required to be consistent throughout a well-defined sub-section of a database system. For example, it may be the case that certain data, such as benefits information, should be consistent within the context of a single work assignment. If the benefits information changes (for example, when a person receives a promotion and becomes authorized to use a company car), then this information is reflected throughout the particular work assignment portion of the database system.
However, some data modifications are neither universal through the database system, nor inherently well-defined in their scope of relevance. For example, if a person has two work assignments within an enterprise, then benefits information related to the first work assignment may not be exactly identical to benefits information of the second work assignment. In the example just given, a modification of benefits information in a first work assignment to reflect authorization for use of a company car may not be identically reflected in a modification of benefits information of the second work assignment. That is, an employee generally would not have access to two company cars.
Various techniques exist for attempting to ensure that data is correct when the scope of the data is neither universal nor well-defined. For example, some applications allow manual entry of such data in all appropriate locations. Aside from difficulties related to the cost and efficiency of such an approach, difficulties may arise that are related to varying authorization levels of the data-entry technicians entering the data. That is, a particular data-entry technician may see that a certain change needs to be made, but may not have the appropriate authorization level to enter the changes in all locations.
Further, it is often the case that enterprise data is time-dependent and/or time-constrained. For example, wage information is often time-dependent, and changes over a person's term of employment. Additionally, wage information may be time-constrained, in that the database system may require that wage information always be present (that is, a person may not be on record as working in a given time period, without being paid some amount during that period).
Often, it is not satisfactory to simply change such time-dependent data when necessary; rather, the time dependent data is changed, and a record of the previous value is stored. In this way, historical data may be kept and compiled for purposes of, for example, tracking employee information over a period of time.